supplied from either the main chassis in the event there is no PIP module or from the PIP 
processing module. 

A viewer watches a mobile betting client 102, for example, a digital television, which is 
able to act as an Internet browser. Commercial applications such as Inet solution enable 
television/browser functionality. A dial-up connection or other communications device, such 
as a LAN connection, can provide Internet connectivity. Along with web browsing functions, 
the mobile betting client is equipped with streaming video and audio reception and display and 
secure connection capabilities. 

Figure 4 depicts a block diagram of the connectivity of the viewer and interaction with 
the provided interactive services. In the preferred embodiments, the mobile betting client 102 
receives an integrated digital broadcast signal (DVB-T). Reception of the signal can be 
accomplished through various means. In the presently preferred embodiment, the mobile 
betting client receives the signal over a GSM, GSM++, POTS, UMTS, or other type of 
connection 104. The mobile connection 104 is itself connected to a network such as an 
extranet, intranet, or the Internet 1 16. Mobile connection to the network 116 takes place in a 
conventional manner over a modem pool 112 with user dial-in and authentication services 114. 

Figure 7A depicts a block diagram of the first sample embodiment of a betting 
provider architecture. In this preferred embodiment, the betting provider information is 
protected from network snooping by a security device such as a firewall 106. At least one 
betting provider server 108 resides behind the firewall. Software running on the server tracks 
viewers (bettors) in various competitions. 

One task of the server 108 is to authenticate viewers. In the presently preferred 
embodiment, a user information (UI) database 702 is maintained. The UI database 702 stores 
user names and associated passwords, user account information, user preferences, and other 
user specific information. In addition to tracking viewers, the server 108 receives and accepts 
bets that have been requested by the viewer to a betting server 110 running on the network 
side of the firewall 106 and connected to a network such as an extranet, intranet, or the 
Internet 116. This betting server 1 10 acts as an interface between interactive services viewers 
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on the network and the actual betting provider. 

The betting provider server 108 receives betting content (questions to the user) and the 
odds of the particular bets from a betting controller 704. The betting controller 704 is 
responsible for creating betting content, controlling the betting event, i.e., opening and closing 
of betting, etc. Betting control software is used to enter and calculate betting content and 
odds and send them to the betting provider server 108. In the presently preferred 
embodiment, the betting provider server 108 stores the betting content and odds in a database 
(BCO) 706. The betting controller 704, via betting control software tracks, the results of the 
betting question and reports the results to the betting provider server 108. 

The results of the bets are stored in a database (BR) 708. Once the results of a 
. particular question are known and stored by the betting provider server 108, software on the 
server calculates payments to the bettors on the particular question. In the presently preferred 
embodiment, electronic accounts stored in the UI database 702 are used for tracking betting 
wins and losses. The results of the event and sub-events (betting questions) are reported to 
the betting server 110. The mobile betting client 102 can then receive the results from the 
betting server 110. 

Figure 7B depicts a block diagram of the betting provider architecture in the second 
* sample embodiment. One important difference between the first and second sample 
embodiments of the betting provider is the manner in which the architecture obtains betting 
information. In the second sample embodiment, the betting provider actively obtains the 
betting information, such as results from sport events, betting rates, validity date of bets, 
teams, status or any betting related activity, from the Internet. The betting provider acquires 
the betting information from a reliable or authentic web site or authentic databases through the 
Internet. It is not required that the betting information is specially entered into the system by. 
for example, betting controller 704. 

As in the first sample embodiment, betting provider 150 is protected from network 
snooping by a security device such as firewall 106. Betting provider 150 preferably comprises 
a plurality of discrete elements, which may be organized into a Local Area Network (LAN). 
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A server 151 performs most of the tasks associated with the betting services. In addition to its 
other functions described below, software running on server 151 authenticates users (bettors) 
and tracks their bets in various competitions. A user information database 702 stores user 
names and associated passwords, user account information, user preferences, and other user 
specific information. It can be accessed by authorized users through firewall 106 
independently of server 151. A firewall 152 prevents unauthorized back-door entry to server 
151 and Game Database 153-21 through user information database 702. 

Unlike betting provider server 108 in the first embodiment, betting provider 150 in the 
second sample embodiment does not use betting content (such as questions to the bettor) and 
the odds of the particular bets created by a betting controller 704 located on the betting 
provider side of firewall 106. Instead, it carries out the process shown in Fig. 7E. First, 
server 151 selects the address(es) of web site(s) containing desired information (Step 751) and 
finds the predetermined information on the web site(s) (Step 752). It takes data, primarily 
betting content and odds, from page(s) on separate web servers 130 and 140 via Internet 116 
and firewall 106 (Step 753). The data content on web servers 130 and 140 can be maintained 
and organized in any manner. In particular, web servers 130 and 140 may be managed either 
with or without particular regard to the accessing of data thereon by betting provider 150. 
The data content can be separated between web servers 130 and 140 in any manner. For 
example, betting information and odds, such as for various sport matches, may be on one 
server while the results of the matches may be on another server. Alternatively, the system 
can process the betting information on a server obtained in order to create betting rates based 
on calculations and statistical models of the event and its probabilities. Exemplary content for 
web servers 130 and 140 is shown in Figs. 7C and 7D, respectively. Although two web 
servers are shown in the sample embodiment shown in Fig. IB, the betting provider may 
collect betting information from any number and variety of systems connected to Internet 116. 

Server 151 runs software which collects the betting information from web servers 130 
and 140 and stores it in a predetermined format (Step 754). The system can actively and 
independently update and bring into effect (put in forced the online information. Exemplary 
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